本ブログは、Splunk Advent Calendar 2024 の 15日目のブログになります。12/25 まで多数投稿されますので是非ご確認ください！

最初に

SIEM は、あらゆる製品のログやイベントデータを収集し、検索や可視化などを通じて企業のシステム全体を分析・調査するテータ活用基盤です。

そんな SIEM の機能の１つにイベントを即時検知してアラート発報する機能があります。

しかし、ログから何をアラート化できるか知らなくて、活用に繋げきれていない。ということもあるかと思いますので、本ブログでは Splunk Cloud を使ってアラート機能とユースケースをご紹介します。

※ Splunk Cloud のアラート設定は、インストールしている App によって作成方法が異なるものもありますが、本ブログのアラート作成は、デフォルトApp の Search & Reporting で作成するフロー方法をご紹介します。

目次

1. SIEM でのアラート運用について
2. Splunk のアラート機能の紹介
3. アラートのユースケース
4. まとめ

SIEM でのアラート運用について

Splunk などの SIEM 製品は、ログを調査するために製品ごとに独自のクエリや SQL などのクエリ言語を使って分析していきます。
そのクエリで得られる結果をもとにアラート化する条件を設けることができます。

その特性から例えば、特定の文字列を含むイベントや、あるイベントの発生回数などをアラート条件にできます。

例えば、監査ログから分かることでは、、

• 特定ユーザのログイン失敗回数のスパイク
• MFA が外れているかどうか
• 意図していない期間の特権アカウントの使用
• 予定にないコードの編集記録

他にもJapan Vulnerability Notes（JVN） などで報告されるような脆弱性が含まれるパッチ適用前のソフトウェアなどを検知したらメール通知を飛ばすなどなど様々あります。

実際にアラートを設定するときは、組織のセキュリティ要件、脅威モデル、リスク評価などに基づいて設計することが重要です。

今回はまず、Splunk Cloud でどんなアラートを設定できるのか、実際に見ていきましょう。

Splunk Cloud のアラート機能の紹介

Splunk Cloud でのアラート設定は基本的に以下の５ステップです。

1. アラートの対象となるクエリを作成
2. 検索結果を基にアラートを作成

• スケジュールとトリガー条件を設定
• 通知方法の設定

3. 保存とテスト

それでは、早速アラートの作成方法を見ていきましょう。デフォルトApp の Search & Reporting を開きます。

アラートの対象となるクエリを作成

vpcflow ログを対象に以下のクエリを作成しました。

index=main source=http:vpcflow-hec sourcetype=aws:cloudwatchlogs:vpcflow vpcflow_action=REJECT
| stats count by src_ip, dest_ip, dest_port
| where count > 10

• vpcflow_action=REJECT となるログを抽出
• 特定の送信元 ip（src_ip）または、宛先 ip（dest_ip）に対して拒否された接続試行数を集計
• 集計した数が 10回以上の結果にフィルタリング

クエリを実行して、期待通りの結果が得られたか確認します。

問題なければ、次にアラートを作成します。

検索結果を基にアラートを作成

検索画面のまま、名前を付けて保存 > アラート を選択します。

すると、アラート設定画面が表示されます。

• タイトル：アラートの内容が一目でわかる内容を入れます。
• 詳細：アラートの説明が必要であれば入れます。
• 権限：プライベートは、自身のSplunk権限範囲内で利用する場合。App内で共有は、自身のデータ閲覧権限のまま他のユーザにも見せる場合。
• アラートタイプ：スケジュール済みは、特定の期間で定期的に自動でログ検索して結果を取得する。リアルタイムは、常にクエリを実行させたり１分や５分など短期間でクエリを実行できます。
• 毎時間実行の部分は、期間を以下のように選択できます。

• 時刻は「毎時間実行」の部分で設定した期間の中でいつ検索を実行させるかを決めます。
• 失効：アラートの寿命を決めます。アクティブ状態を保持する期間を決めることで有効期間を管理する目的があります。

次にアラートの生成条件です。

• 次の条件の時にアラートを生成：以下の条件を選択できます。

基本的に、結果数を選択し、あらかじめ作成したクエリにヒットする結果をトリガーするのがいいと思います。

カスタムを選択すると、さらに特定のフィールド数に基づいたアラートを設定できます。例えば、追加で search count > 150 など、他の要素を含めることができます。

• 抑制：定期的にアラートが実行されるので、アラートの重複を防いでノイズを減らす目的があります。

この場合、60分は同じアラートを生成しないようになります。

次にアラート発報後のアクションを決めます。

アクション追加を選択すると、、

メールに送信したり、webhook で Slack などに通知する設定を施せます。ここでは、メールを例にご説明します。

宛先：アラートを通知するメールアドレスを入力します。

優先度：アラートの重要度を指定します。

メールの件名や本文を入力します。Splunk であらかじめ用意されている変数を使うことができます。例えば $ で name を囲うことで、アラート名を拾って表示してくれます。

チェックボックスは、画像の意味のままで、メールにトリガー条件を表示したり、csv ファイルにまとめて添付してくれたり、splunk web に直接アクセスするリンクを入れてくれたりします。

他にも、次のブログで紹介されているように「生成アラートに加える」を選択すると、Splunk 上でアラートの管理も行うことができるようになります。
Splunkでエラーメッセージを元にアラートを送る（Qiita の Splunk Advent Calendar 2024 のブログに飛びます。）

アラートのユースケース

先ほどの例では、異常な拒否パケットの増加検知するアラートを作成していました。
他にも、vpcflow ログを使ってアラート活用に向けていくつかのシナリオを上げてみます。

特定ポートへの大量の接続

攻撃者が例えば ssh の 22番ポートへ大量に接続試行を行った場合のアラート条件を考えてみます。

index=hoge sourcetype=huga:vpcflow dest_port=22
| stats count as ssh_attempts by src_ip
| where ssh_attempts > 50

以下の様に dst_port=22 のログで where の条件にヒットした src_ip のみを抽出できます。

アラート条件：結果数１より大きい

とすることで、50件以上の接続があれば検出して、ブルートフォース攻撃の早期検出に繋がりそうです。

大量データ転送の検知

特定の送信元IPが異常に多くのデータを送信している場合にアラート条件を考えてみます。

index=hoge sourcetype=huga:vpcflow
| stats sum(bytes) as total_bytes by src_ip
| where total_bytes > 100000000

以下の様に where の条件にヒットした total_bytes のトラフィックのみを抽出できます。

アラート条件：結果数１より大きい

とすることで、100000000 より多いバイト数のトラフィックを検出して、データの持ち出しや、異常なトラフィックを検出できます。

まとめ

今回はアラートの基本的な設定手順と３つのユースケースをご紹介しました。

実は他にも lookup テーブルを使ったスケジュールやアラートで、より高度な活用方法もあります。例えば、意図していないロケーションからのアクセスや、自社グローバル ip を経由していないトラフィックの検知など、使い方次第で様々なユースケースがあります。

別の機会にブログで紹介します。